home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / doors_2 / xrdor211.zip / NEWIN206.DOC < prev    next >
Text File  |  1993-01-31  |  23KB  |  404 lines

  1. (these are in reverse order - XRSDoor 2.06 back to XRSDoor 2.01)
  2.  
  3.  
  4.  
  5.     XRS "eXpress Response System" (R) Door version 2.06 changes:
  6.  
  7.  
  8. 0) Lord help us - this one's been moved from BC++ 2.0 to Borland C++ 3.0!
  9.  Watch for "unusual" new features, please!  I had to turn optimization off
  10.  for one entire module (the name lookup binary search) already.
  11.  
  12. 1) XRSDoor supports "No Reply" areas if the SysOp enables it (only!).  Any
  13.  area you have marked "Read-Only" becomes a read-write but not quote-reply
  14.  message area.  (in other words, the use can make an area readable, and they
  15.  can enter an original new message but they cannot quote or reply to existing
  16.  messages.  This support is exclusive - one way or the other - either "Read
  17.  Only" really means read-only, or it means no-reply.  Put the new "No Reply"
  18.  parameter into your QMXSETUP.CFG control file to enable this feature.  Note
  19.  that it's an all or nothing proposition: either you have all areas marked
  20.  this way really read-only, or they're all no-reply!  If a user enters any
  21.  new message into the "No Reply" conference, it is always marked "public".
  22.  YOU ARE OVERRIDING THE BBS SECURITY AND ANYONE CAN ACCESS AND LEAVE MESSAGES
  23.  IN ALL CONFERENCES MARKED "READ-ONLY" AS LONG AS THEY HAVE AT LEAST A "READ
  24.  ACCESS" LEVEL FOR EACH GROUP IF YOU ENABLE THIS OPTION!  Note also that the
  25.  areas which are "Read-Only" (regardless of whether or not you turn this on)
  26.  will still be read-only for all XRS users except XRS 5 "Mod 3" or higher.
  27.  (in other words, only XRS 5 "Mod 3" or later supports "No Reply")
  28.  
  29. 2) Chuck Forsberg seems to keep changing DSZ.COM to suit, and this time he's
  30.  restricted the 'restrict' command to registered copies.  XRSDoor has always
  31.  used the "restrict" on uploads to protect you from users to uploading to
  32.  current directory only.  This is now a registered DSZ 'feature', so XRSDoor
  33.  doesn't use it by default.  (see below - you can re-enable it with DSZPARM
  34.  or the "SET DSZOPT=-r" environment string if you have a registered copy)
  35.  
  36. 3) We still didn't get "DSZPARMS xxx" right in 2.05: you couldn't change any
  37.  parameter appearing after the protocol.  In this version, you can use "%s"
  38.  (lower-case 's'!) to substitute for the protocol, if you don't the protocol
  39.  is added to the end of your parameter string.  Example: "DSZPARMS handshake
  40.  both restrict estimate 0 $B %s -m" to turn on "MobyTurbo".
  41.  
  42. 4) The "Limit xxxx" parameter allows you to set it up to 20,000 messages!
  43.  You should use this feature with caution!  Even though XRSDoor computes the
  44.  time left -vs- time required to pack 'x' number of messages, it is possible
  45.  that a user with download problems could conceivably tie up your system for
  46.  an extended period of time, although XRSDoor checks time remaining between
  47.  offers to try again on downloads, so if they aren't dialed in at 9600+ and
  48.  receiving at 300 baud, it shouldn't be a problem.  A 20,000-message mailbag
  49.  is about 20MB in size compressed, and requires 60 to 65MB free space on the
  50.  drive to create and pack! (and quite a while to transfer even at 1700 cps!)
  51.  Users should be cautioned that picking more than 5000 messages in a mailbag
  52.  may be unreadable in a system without EMS memory (the heap expander could
  53.  allow me to go up to 256K messages, but that's a bit much!).  A full 20,000
  54.  message mailbag requires a system with at least 2MB EMS memory!.
  55.  
  56. 5) XRSDoor will allow you to call it with command-line parameters which can
  57.  either eXpress-Upload mail (only) or eXpress-Download mail (only).  To use
  58.  these functions, put "/UPLOAD" or "/DownLoad" as the only parameter on the
  59.  command-line in your BBS menu configuration.  Auto-Download sends up to the
  60.  the limit you defined in your "Limit xxx" parameter (default 1500).  Local
  61.  (console) users cannot upload so this option make no sense for them!  (but
  62.  XRSDoor checks for it though - and gracefully exits if you try)  Downloads
  63.  are allowed for Local users, but they are saved in compressed format and
  64.  not transmitted, of course.
  65.  
  66. 6) You can force XRSDoor to use RA files with "BBSType RA" in QMXSETUP.CFG
  67.  or force XRSDoor to put any of the following identifiers into the USERx.XRS
  68.  file: "PCBoard", "Quick", "Super", "WildCat", "Tag" and "MKBBS".  Only XRS
  69.  5.0 "Mod 3" and later recognize the last two.  Don't read any more into this
  70.  than it says: you can force XRSDoor to place one of the above identifiers in
  71.  your mailbags, so that XRS returns mail with origin lines that agree with
  72.  the actual BBS type you are using, regardless of which control files you are
  73.  using - but you still must have either a complete set of QuickBBS (either
  74.  2.0x-2.6x or 2.7x+) or RA format control files and message databases to run
  75.  XRSDoor!  Note that one special case: "BBSType RA" causes XRSDoor to ignore
  76.  any QuickBBS control files which might be in the directories (because you
  77.  use QEcho, or whatever) and only pay attention to RA configuration files.
  78.  In all other cases, the *only* effect is to cause XRSDoor to put the tag in
  79.  USERx.XRS which corresponds to the above BBS type.
  80.  
  81. 7) You can force the "EXPRESS.BBS" file to be echoed to the console (i. e.
  82.  displayed online) by placing an exclamation point ("!") as the first byte
  83.  in the file (in which case it is skipped).  This might be useful in notices
  84.  about program changes or new features, which you could run for a short time
  85.  after a new program release, etc.  A sample "EXPRESS.BBS" file is enclosed.
  86.  
  87. 8) You can force XRSDoor to export 'kludge' lines either only for the SysOp
  88.  or for all users.  "Show SysOp Kludges" in QMXSETUP.CFG will turn it on for
  89.  the SysOp only, or "Show User Kludges" will turn them loose for everyone.
  90.  For the SysOp (only) in either case, XRSDoor exports any SEENBY and/or PATH
  91.  lines it finds - but never shows these for users.
  92.  
  93. 9) XRSDoor marks messages "To You" for aliases, and searches outside selected
  94.  areas for messages to the alias if that "<O>ption toggle" switch is set.
  95.  
  96. 10) The cursor is lined-up correctly under the first character of menus.
  97.  
  98.  
  99.  
  100.  
  101.       XRS "eXpress Response System" (R) Door version 2.05 changes:
  102.  
  103. 1) The "Short Month" displayed for saved mailbags is corrected.  This was off
  104.  by one month before (and I had two tables in XRSDoor with the same data).
  105.  
  106. 2) Packing with "ARC" (now using PKPak) with named mailbags works again.
  107.  
  108. 3) The previously undocumented "DSZPARMS xxx yyy zzz etc up to 65 characters"
  109.  parameter in QMXSETUP.CFG is fixed (and documented <grin>...).  You can use
  110.  this to fine-tune your DSZ.COM or GSZ.EXE calls - the default parameters are
  111.  "handshake xxx estimate 0 yyy" where 'xxx' = "both" if user > 2400 baud or
  112.  "LockBaud" otherwise "on" and 'yyy' = the actual connect rate (as opposed to
  113.  the possibly locked FOSSIL rate).
  114.  
  115. 4) The bug that cause QuickBBS 2.75 "Alias Only" areas to be marked "Alias
  116.  Allowed" instead is fixed, and another bug which caused it not to properly
  117.  update "LASTREAD.BBS" was fixed as well.
  118.  
  119.  
  120.  
  121.  
  122.  
  123.       XRS "eXpress Response System" (R) Door version 2.04 changes:
  124.  
  125.  
  126. 1) XRSDoor uses "4D-PACK.XRS" (instead of 4D_ - the underscore messes up the
  127.  XRS CP/M clone (CRR) written by Paul Martin).  If you had "4D_PACK.XRS" out
  128.  there, you need to change the name to "4D-PACK.XRS" for version 2.04!
  129.  
  130. 2) When XRSDoor is run under "PackBags" in 'demand pack' mode, it will check
  131.  for uploaded files as if the user were online, therefore enabling processing
  132.  of UREQ (UserRequest) messages to XRS to add or delete echomail areas.  Note
  133.  that file-requests are not possible in this mode.  If you have MkXrs enabled
  134.  it *is* called using the "MKXRS L FIRSTNAME LASTNAME" parameter sequence.
  135.  
  136. 3) XRSDoor is compiled with Borland C++ "BCCX" and the coding error in the
  137.  "Scroll" routine in Borland's library has been repaired.
  138.  
  139. 4) If you tell XRSDoor to erase all prepacked mail and the mail is not in
  140.  the current subdirectory, you no longer go into an endless loop. (sorry!)
  141.  It also displays a list of the filenames as it deletes them.
  142.  
  143. 5) The date each prepacked mailbag was created is displayed along with the
  144.  filesize and name.
  145.  
  146. 6) The misleading "Quit .. and delete" message if you are downloading some
  147.  prepacked mail is fixed (if you pick "<Q>uit" at this point, the prepacked
  148.  mail is *not* deleted!).
  149.  
  150. 7) If you hit only "<ENTER>" when prompted to delete all prepacked mail,
  151.  XRSDoor no longer leaves the sub-menu and continues - instead it allows
  152.  you to chose between "<D>ownload", "<S>ave" and "<E>rase" again.
  153.  
  154. 8) If "PackBags" is run and the is no "QMX_CONF.SYS" file found, it exits
  155.  gracefully without hanging the system. (oops #2!)
  156.  
  157. 9) If XRSDoor detects an "unknown file compression" or alien upload in the
  158.  inbound directory, when it moves the file into the "XRS_DOOR.BAD" subdir,
  159.  it places a messages telling the SysOp into the system log file.
  160.  
  161. 10) Now says "Prepacked" mailbags where it used to say "Packpacked" (must
  162.  have been a late-night event!).
  163.  
  164. 11) If "Alias Required" is set (or force handle), then XRSDoor turns on a new
  165.  bit in ACCESSx.XRS which tells XRS not to bother to ask.
  166.  
  167. 12) XRSDoor now uses a new "Exec_Swap()" routine which was written by Thomas
  168.  Wagner of Ferrari GmBH in Germany.  It supports swap to LIM/EMS, XMS or disk.
  169.  Note that the "Swap" parameter in QMXSETUP now ignores any disk specified,
  170.  and execSwap() uses the "SET TEMP=" from the environment instead.  For best
  171.  speed, this should point to a RAMdrive (only matters if you have no [or
  172.  insufficient] LIM/EMS or XMS memory).  This is a faster and slightly more
  173.  efficient routine than the old swapper - it only leaves a 'stub' of about
  174.  1.5K in memory.  Note that there is a potential problem in disk swapping
  175.  usage - since Exec_Swap() uses the "SET TEMP=" from your DOS environment (if
  176.  found), if it points to a subdirectory that doesn't have sufficient free
  177.  space, then swap-out will fail.  The amount of space to swap out XRSDoor is
  178.  128K.  If you have less than that amount of space on the "TEMP" drive and
  179.  enable "Swap", you must use a batch file and set the point "SET TEMP=" to
  180.  another drive when XRSDoor is running, then switch it back to the original
  181.  subdirectory when it is through.  (also, note that if you have 128K of EMS
  182.  or XMS memory free for swapping, this does *not* apply to you!)
  183.  
  184. 13) To enable alias support, the user must go to the "<O>ption Toggle" switch
  185.  configuration sub-menu and turn on the "Using XRS 4.52 or later?" option.  I
  186.  had to do this, or it would cause any older XRS versions to quit with a "Bad
  187.  User" exit 91 error (file tampering).  XRSDoor now assumes all users have XRS
  188.  3.21 or later (therefore always produces "named mailbags").  XRSDoor puts a
  189.  special "tag" into the user file to enable user aliases.  Without the special
  190.  signature, aliases are disabled.  Aliases are not supported by any versions
  191.  of XRS prior to 4.52!  Unless the user enables alias support for himself, an
  192.  old-style 43-byte "USERx.XRS" file is written regardless of whether or not he
  193.  has a "registered" alias, if he enables this feature, and new 68-byte file is
  194.  written which includes his alias and the file "signature" is updated.  The
  195.  same switch which formerly was used to indicate "Using XRS 3.21" or later was
  196.  reused for this option - therefore anyone using XRS 3.20 or prior versions
  197.  will no longer receive "unnamed mailbags" and *must* upgrade at this point!
  198.  
  199. 14) If you use "SysOpOut xxxx" and want to enable 4D-packing, just copy the
  200.  '4D-PACK.XRS' file over to your SysOpOut subdirectory (or create one there).
  201.  
  202. 15) An ugly bug in my code caused the program to go nuts on the fifth call to
  203.  XRSDOOR in one execution of PackBags (go figure!).  I wasn't closing the user
  204.  file "USERS.BBS" every time, and reopened it (in share mode if applies) each
  205.  time.  This should have eventually exhauseted your available file handles and
  206.  died, but I'm at a loss as to why this error would cause the computer to go
  207.  nuts reading a file and start streaming output endlessly to the datafiles!
  208.  PackBags.Exe version is now 0.50 - I think it's about ready for "prime time".
  209.  
  210. 16) The "MSGTXT.BBS" file is closed as soon as extraction is completed and
  211.  not held open even during compression and download.
  212.  
  213. 17) XRSDoor uses PKPAK and PKUNPAK instead of PKARC and PKXARC.
  214.  
  215. 18) New XRUserEd.Exe program (which does *NOT* require the old XRS$CORE.RTL or
  216.  XRS$ALL.DTA files to run!) that runs under DOS 5.0 without "LoadFix.Exe".
  217.  (But it *does* need the new XRS 4.52 standard "XRSLANG.DLL" file for English
  218.  language support or any other foreign language XRS 4.52/5.0-compatible native
  219.  language support binary overlay plus the XRSCORE.DLL library for Borland C++
  220.  and C_Worthy run-time library - after all - what did you expect from a < 9.5K
  221.  program?  (does an awful lot, eh?)
  222.  
  223.  
  224.  
  225.  
  226.  
  227.       XRS "eXpress Response System" (R) Door version 2.03 changes:
  228.  
  229. Went back to the original release BC++ 2.0 to eliminate the bug in the newer
  230. compiler which caused wierd "local" displays (although the user side was OK)
  231.  
  232.  
  233.  
  234.  
  235.  
  236.       XRS "eXpress Response System" (R) Door version 2.02 changes:
  237.             (since version 2.01)
  238.  
  239. 1) PackBags.Exe is an automatic (pre-packing) mailbagger for XRSDoor.  It
  240. scans through your QMX_CONF.SYS file looking for your "Priveleged" users
  241. which you have marked with the "Prepack" bit-flag, and automatically creates
  242. the files required and calls "XRSDoor!.Exe" (if it is not found "XRSDoor.Exe")
  243. to do the actual extraction and compression.  Each person's pre-bagged mail
  244. will be saved under a unique 8-hexidecimal digit name, with the user-selected
  245. extent depending on which compaction he has chosen (i.e. "2fa839d1.ZXR" up to
  246. *.ZX9, assuming the user selected PKZip packing - at most 10 files saved for
  247. any one user.  PLEASE BE CERTAIN YOU HAVE XRSDOOR SETUP AND OPERATING PROPERLY
  248. BEFORE YOU EVEN THINK ABOUT IMPLEMENTING THIS PROGRAM!  You must chose which
  249. users are allowed to have prepacked mail by using the "XRUserEd.Exe" program
  250. that comes with XRSDoor (set the 'P' bit - "Prepack" under the "Toggle switch"
  251. submenu).  I would suggest that you only run PackBags once a day, in which
  252. case it will store up to 10 mailbags for a user while they are on vacation,
  253. etc.  (once it has 10 mailbags on "hold" it will not pack any more for that
  254. user)  PackBags stores its log in a separate "PackBags.LOG" file which you
  255. may wish to delete occasionally, after assuring it is working correctly.
  256.           * * * * * *  W A R N I N G  * * * * * *
  257. Please be careful here - you can easily get into the habit of saving 100's of
  258. kilobytes of mail for people, which XRSDoor is designed to avoid (i.e. prepack
  259. problems associated with supporting a large number of "real" points).  This
  260. feature should be reserved for your best users depending upon your disk drive
  261. capacity, etc.  Using this feature wisely to give your best XRS users mail on
  262. demand (and prepacking during the "midnight" or one event early each day) can
  263. save users still more time online (and give you an opportunity to have more
  264. users online per day, too!).
  265.  
  266. 2) Several minor changes were made to accommodate "PackBags.Exe" - the
  267. automatic mailbagger.  XRSDoor was also modified to look for the special
  268. saved files, and offer to download them as soon as the user comes into the
  269. door the next time (or he may chose to defer or store them until later, or
  270. delete them).  PackBags creates a mailbag with a unique name by performing a
  271. 32-bit CRC on the username, and renames the normal output file.  XRSDoor now
  272. knows the 'named mailbag' name for saved mailbags for each user.  For the time
  273. being, batch protocols only (True Y-Modem, Z-Modem or G-ymodem) must be used.
  274.  
  275. 3) The FOSSIL input routine immediate "timeout" if the user started XRSDoor
  276. within three minutes before midnight is fixed.
  277.  
  278. 4) New QMXSETUP.CFG parameter "Minimum xxx" allows you to set a minimum count
  279. of new messages in the mail databases before XRSDoor.Exe will prepack mail -
  280. range is from 50 to 1000 messages.  It only affects XRSDoor when it is called
  281. by PackBags.  I would suggest that you set it to at least 250 messages - note
  282. that the maximum number of messages packed (which has nothing to do with how
  283. many new messages total are on file) is going to always be the number you set
  284. using "Limit" parameter, which will avoid creating bundles too large for your
  285. your users.  The default is 250.  Setting this to a reasonable number, say
  286. 500 or 1000 (depending on the average daily volume of mail coming into your
  287. system) gives you the ability to prepack mail more often, but only when a
  288. certain minimum number of new messages have been received.
  289.  
  290. 5) New QMXSETUP.CFG parameter "PackbagPath xxxxx" allows you store prebagged
  291. mail in another subdirectory insteaed of the current directory.  Parameter is
  292. *REQUIRED* for multi-node systems to work properly, and in this case must give
  293. a complete PATH.  THE SUBDIRECTORY *MUST* BE ON THE SAME DRIVE!  For single
  294. line systems, using "PackbagPath C:\SaveBags" would store prebagged mail under
  295. a subdirectory named "SAVEBAGS" off the root of the C drive for example, and
  296. "PackbagPath C:\QMX\SAVEBAGS" would save all packed mail in that subdirectory
  297. for a multi-line system.  Be sure to include the complete path - be certain
  298. that it already exists! (and that it is on the same drive)
  299.  
  300. 6) New QMXSETUP.CFG parameter "GMODEM" enables G-Modem for selection.  Prior
  301. versions always showed it, even though it may have been inappropriate.  If you
  302. have an error-correcting modem, you should turn this on, otherwise it will no
  303. longer be offered.  Note that if you don't have a registered copy of DSZ.COM
  304. or GSZ.COM, this parameter will not function, anyway!
  305.  
  306. 7) Normally, "PackBags.Exe" searches QMX_CONF.SYS for users the SysOp has
  307. marked for PrePack, creating the EXITINFO.BBS and DORINFO1.DEF files for each
  308. user and calling XRSDoor.  If you type a name on the command-line, PackBags
  309. only looks for a matching username in the file, and if found creates the two
  310. required files, packs mail for that one person (without regard to "Minimum")
  311. and exits.  This allows "On Demand" packing (for someone not necessarilly
  312. marked for prepacking) - this might be used for a "Mailer Request" function.
  313.  
  314. 8) PackBags knows nothing about which type of Hudson-style BBS it is running
  315. on, and needs to know if the USERS.BBS and/or QMX_CONF.SYS files are hiding
  316. in another subdirectory.  If one (or both) are, use a new "MessagePath xxxxx"
  317. QMXSETUP.CFG parameter, where 'xxxxx' is the path to the file(s).
  318.  
  319. 9) The error which allowed users to send "Crash" netmail if they had the
  320. "Prompt for maximum number of messages" bit set is fixed.  Note that XRSDoor
  321. determines whether or not a user has "Crash" priveleges solely by the flag in
  322. QMX_CONF.SYS (which you set with XRUserEd.Exe) - it pays no attention at all
  323. to any other settings.
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.       XRS "eXpress Response System" (R) Door version 2.01 changes:
  331.             (since version 2.00)
  332.  
  333.  
  334. 1) Fixes problem with RA 1.10 versions, which provide the true carrier rate
  335. for new connect speeds when used with the new CCITT V.32bis modems.  XRSDoor
  336. now recognizes 14400, 12000 and 7200 BPS rates as legitimate.
  337.  
  338. 2) You can select "AR<J>" from the compression type selection sub-menu in the
  339. configuration section.  The menu which was previously here has been replaced
  340. with a simpler one-line prompt.  XRSDoor defaults to "PKZip" for packing.
  341. ARJ is only recognized by XRS 4.50 versions dated June 15th, 1991 or later!
  342.  
  343. 3) "InDir" can be on another drive, allowing you to use a RAM-disk, etc.
  344.  
  345. 4) XRSDoor recognizes and includes "4D_PACK.XRS" in every mailbag if you
  346. place that file in your subdirectory (content unimportant - can by 0 length).
  347. This forces XRS 4.50 versions dated June 15th, 1991 or later to return you a
  348. true 4D packet with zone:net/node.point all filled out in the *.PKT header.
  349. IMPORTANT NOTE:  DO *NOT* USE "POINT 0" IN COMBINATION WITH 4D_PACKing! (the
  350. result will be that both the 4D "from" and "to" addresses are idential...)
  351.  
  352. 5) A new "XRUserEd.Exe" is included that will show/set "ARJ" for compression.
  353. XRUserEd requires both the file "XRS$ALL.DTA" and "XRS$CORE.RTL" found in the
  354. XRS release archives.  Also, note that you must be in the same directory as
  355. the "QMX_CONF.SYS" file when you run it (and if "AREAS.BBS" is in a different
  356. subdirectory, that subdirectory must be used as a command-line parameter).
  357.  
  358. 6) "Alien" uploaded files are moved to a subdirectory named "XRS_DOOR.BAD"
  359. and deleted from the "InDir" (anything that cannot be unpacked/interpreted).
  360. If the subdirectory doesn't exist, XRS creates it.
  361.  
  362. 7) "MSGTOIDX.BBS" is no longer left open during message pack and download.
  363.  
  364. 8) The "Clean_Up()" routine is executed as soon as files are successfully
  365. compressed instead of after the download is completed.  This eliminates all
  366. of the *.XRS files packed into a mailbag before the transfer, optimizing use
  367. of disk space (especially important on multi-line systems / large mailbags).
  368.  
  369. 9) XRS can use the new "GSZ.EXE" (full-screen version of DSZ).  Put "Use GSZ"
  370. into your QMXSETUP.CFG file, it is used instead of DSZ.COM for transfers.
  371.  
  372. 10) If "MkXrs" is called to import mail after an upload, the "HighMsgRead"
  373. pointer is updated properly, so users with the "Include" (from me) toggle on
  374. do not see their own messages twice - when they are uploaded and next time.
  375.  
  376. 11) If the file "QUICKCFG.DAT" is found, QuickBBS 2.75 or later format files
  377. are used and RA and SuperBBS support checks are bypassed.  XRSDoor uses that
  378. file and "MSGCFG.DAT" instead of CONFIG.BBS (or CONFIG.RA and MESSAGES.RA).
  379. (note - this includes full multi-line support with file-sharing)  XRSDoor
  380. also recognizes AKA addresses for QuickBBS 2.75 and later.   XRSDoor pulls
  381. the node number for Quick275+ from the QUICKCFG.DAT file and ignores the "SET
  382. TCNODE=x" in the environment (if any).  If multi-line QuickBBS 2.75 or later
  383. is being used, the "QMX_CONF.SYS" (user default selections file) is kept in
  384. the message subdirectory - if you now have it somewhere else (in the current
  385. directory) you *MUST* move it!  The "SET QUICK=xxxx" environment string is
  386. used to find files (i.e. "xxxCFG.DAT") if they are not in the current dir.
  387.  
  388. 12) The availability of "Crash" netmail works for any version of QuickBBS.
  389.  
  390. 13) XRSDoor puts the alias supported by RA 1.0 and later or QuickBBS 2.75 and
  391. later into the USERx.XRS file for use by future XRS versions.
  392.  
  393. 14) The status bar no longer scrolls up (and off) the screen if you have lots
  394. of new files displayed.
  395.  
  396. 15) XRSDoor sets the "Alias" flag in ACCESSx.XRS if the SysOp allows it, the
  397.  "Local" flag in ACCESSx.XRS for local areas, and the "Netmail" bit is set
  398.  for all netmail areas, not just the first one encountered.  WARNING!!!  If
  399.  your echomail mangler insists it can't handle origin-less message, you can
  400.  *NOT* use the "Local" bit, since XRS will put a local tagline rather than a
  401.  complete Fido-spec tear and origin line into "Local" messages (4.52!)  If
  402.  this is the case - you have two choices - get a better mail mangler or set
  403.  the parameter for the local areas to make them look like echomail again...
  404.